Processing Online Transactions

ABSTRACT

Disclosed are systems and methods for managing transactions in which an order is specified online and payment is received at a point of sale (POS). Methods are disclosed for managing payment for such transactions at a POS, including transactions involving payment for both in-store purchases and online orders. Methods are also disclosed for managing inventory and price changes for such transactions where payment can occur at any time in a pay period following order creation. Also disclosed are methods for processing refunds for online orders for which payment was made at a POS. Finally, methods for preventing fraud and abuse as well as restricting the availability of this payment method for certain items are disclosed.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 61/624,975 filed Apr. 16, 2012 and entitled Novel Approach to MakingPayments, which is hereby incorporated herein by reference in itsentirety.

BACKGROUND

1. Field of the Invention

This invention relates to receiving payment for online purchases.

2. Background of the Invention

In ecommerce transactions, the typical payment method is a credit ordebit card. Other electronic accounts may also be used to pay for anonline purchase, but these accounts are typically linked to some sort ofbank or credit account. These payment methods result in additional costsdue to transaction processing, fraud processing, and chargebackexposure.

There are also many “unbanked” and “under-banked” customers that do nothave a credit or debit card and do not qualify for alternatives, butwant to purchase items online. These customers typically pay with cashfor in-store transactions. In addition, many potential customers are notcomfortable entering their credit card information on a web site. In athird party survey of online users, 12-18% did not shop online. Of theseusers, 44% cited not wanting to share financial information online asthe reason for refraining from online shopping.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered limiting of its scope, the invention will be describedand explained with additional specificity and detail through use of theaccompanying drawings, in which:

FIG. 1 is a block diagram of a computing device suitable forimplementing embodiments of the present invention;

FIG. 2 is a block diagram of a network environment suitable forimplementing embodiments of the present invention;

FIG. 3 is a block diagram of components for processing onlinetransactions in accordance with embodiments of the present invention;

FIG. 4 is a block diagram of data structures for supporting processingonline transactions in accordance with embodiments of the presentinvention;

FIG. 5 is a process flow diagram of a method for processing an onlinetransaction in accordance with an embodiment of the present invention;

FIG. 6 is a process flow diagram of an alternative method for processingan online transaction in accordance with an embodiment of the presentinvention;

FIG. 7 is a process flow diagram of a method for processing an onlinetransaction including partial payment using store credit in accordancewith an embodiment of the present invention.

FIG. 8 is a process flow diagram of a method for processing an onlinetransaction including identifying stores eligible for receiving paymentin accordance with an embodiment of the present invention;

FIG. 9 is a process flow diagram of a method for selecting candidatestores for presentation to a customer in accordance with an embodimentof the present invention;

FIG. 10 is a process flow diagram of a method for processing payments ata point of sale (POS) while a merchant system is offline in accordancewith an embodiment of the present invention;

FIG. 11 is a process flow diagram of a method for processingtransactions including payment for in-store and online purchases;

FIG. 12 is a process flow diagram of an alternative method forprocessing transactions including payment for in-store and onlinepurchases;

FIG. 13 is a process flow diagram of a method for processing payment foronline orders at a POS in order to prevent duplicate payments inaccordance with an embodiment of the present invention;

FIG. 14 is a process flow diagram of a method for processing paymentsfor layaway and online orders in accordance with an embodiment of thepresent invention;

FIG. 15 is a process flow diagram of a method for processing refunds inaccordance with an embodiment of the present invention;

FIG. 16 is a process flow diagram of another method for processingrefunds in accordance with an embodiment of the present invention;

FIG. 17 is a process flow diagram of another method for processingrefunds in accordance with an embodiment of the present invention;

FIG. 18 is a process flow diagram of a method for processing reductionin price for items for which payment at a POS is the selected paymentmethod in accordance with an embodiment of the present invention;

FIG. 19 is a process flow diagram of another method for processingreductions in price in accordance with an embodiment of the presentinvention;

FIG. 20 is a process flow diagram of another method for processingreductions in price in accordance with an embodiment of the presentinvention;

FIG. 21 is a process flow diagram of a method for determiningeligibility of an online order for POS payment in accordance with anembodiment of the present invention;

FIG. 22 is a process flow diagram of a method for specifying eligibilityof an item for payment at a POS in an online transaction in accordancewith an embodiment of the present invention;

FIG. 23 is a process flow diagram of a method for determining theeligibility of an item in an item hierarchy in accordance with anembodiment of the present invention;

FIG. 24 is a process flow diagram of a method for managing inventoryassociated with online orders with payment taking place at a POS inaccordance with an embodiment of the present invention; and

FIG. 25 is a process flow diagram of a method for preventing fraud andabuse in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

It will be readily understood that the components of the presentinvention, as generally described and illustrated in the Figures herein,could be arranged and designed in a wide variety of differentconfigurations. Thus, the following more detailed description of theembodiments of the invention, as represented in the Figures, is notintended to limit the scope of the invention, as claimed, but is merelyrepresentative of certain examples of presently contemplated embodimentsin accordance with the invention. The presently described embodimentswill be best understood by reference to the drawings, wherein like partsare designated by like numerals throughout.

The invention has been developed in response to the present state of theart and, in particular, in response to the problems and needs in the artthat have not yet been fully solved by currently available apparatus andmethods. Accordingly, the invention has been developed to provideapparatus and methods for managing online transactions wherein an optionis provided to pay for a transaction at a POS located in a store.

In one aspect an order is created online, such as by using a webbrowser, and POS payment is selected as the payment method. An orderidentifier may be transmitted to the customer, who then presents theorder identifier at a POS. The POS retrieves order information for theorder identifier and receives payment of a purchase price for the order.The POS then transmits acknowledgment of payment of the purchase priceto a merchant system that then authorizes fulfillment and otherwiseprocesses the order.

Various methods for supporting these types of transactions are alsodisclosed and claimed herein. Included are methods for managing theactual transaction, as well as methods for processing refunds, managinginventory, restricting eligibility of items for this form of payment,preventing fraud and abuse, and managing other aspects of thetransaction.

An embodiment in accordance with the present invention may be embodiedas an apparatus, method, or computer program product. Accordingly, thepresent invention may take the form of an entirely hardware embodiment,an entirely software embodiment (including firmware, resident software,micro-code, etc.), or an embodiment combining software and hardwareaspects. Such embodiments may all generally be referred to herein as a“module” or “system.” Furthermore, the present invention may take theform of a computer program product embodied in any tangible medium ofexpression having computer-usable program code embodied in the medium.

Any combination of one or more computer-usable or computer-readablemedia may be utilized. For example, a computer-readable medium mayinclude one or more of a portable computer diskette, a hard disk, arandom access memory (RAM) device, a read-only memory (ROM) device, anerasable programmable read-only memory (EPROM or flash memory) device, aportable compact disc read-only memory (CDROM), an optical storagedevice, and a magnetic storage device. In selected embodiments, acomputer-readable medium may comprise any non-transitory medium that cancontain, store, communicate, propagate, or transport the program for useby or in connection with the instruction execution system, apparatus, ordevice.

Computer program code for carrying out operations of the presentinvention may be written in any combination of one or more programminglanguages, including an object-oriented programming language such asJava, Smalltalk, C++, or the like, and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on acomputer system as a stand-alone software package, on a stand-alonehardware unit, partly on a remote computer spaced some distance from thecomputer, or entirely on a remote computer or server. In the finalscenario, the remote computer may be connected to the computer throughany type of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).

The present invention is described below with reference to flowchartillustrations and/or block diagrams of methods, apparatus (systems) andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, as well as the combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions or code. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture. This article of manufacturewill include instruction means that implement the function/act specifiedin the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus. to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

Embodiments can also be implemented in cloud computing environments. Inthis description and the following claims, “cloud computing” is definedas a model for enabling ubiquitous, convenient, on-demand network accessto a shared pool of configurable computing resources (e.g., networks,servers, storage, applications, and services) that can be rapidlyprovisioned via virtualization and released with minimal managementeffort or service provider interaction, then scaled accordingly. A cloudmodel can be composed of various characteristics (e.g., on-demandself-service, broad network access, resource pooling, rapid elasticity,measured service, etc.), service models (e.g., Software as a Service(“SaaS”), Platform as a Service (“PaaS”), Infrastructure as a Service(“IaaS”)), and deployment models (e.g., private cloud, community cloud,public cloud, hybrid cloud, etc.).

FIG. 1 is a block diagram illustrating an example computing device,labeled computing device 100. Computing device 100 may be used toperform various procedures, such as those discussed herein. Computingdevice 100 can function as a server, a client, or any other computingentity. It can perform various monitoring functions as discussed herein,and can execute one or more application programs, such as theapplication programs described herein. Computing device 100 can be anyof a wide variety of computing devices, such as a desktop computer, anotebook computer, a server computer, a handheld computer, tabletcomputer and the like.

Computing device 100 includes one or more processor(s) 102, one or morememory device(s) 104, one or more interface(s) 106, one or more massstorage device(s) 108, one or more input/output (I/O) device(s) 110, anda display device 130 all of which are coupled to a bus 112. Processor(s)102 include one or more processors or controllers that executeinstructions stored in memory device(s) 104 and/or mass storagedevice(s) 108. Processor(s) 102 may also include various types ofcomputer-readable media, such as cache memory.

Memory device(s) 104 include various computer-readable media, such asvolatile memory (e.g., random access memory (RAM) 114) and/ornonvolatile memory (e.g., read-only memory (ROM) 116). Memory device(s)104 may also include rewritable ROM, such as flash memory.

Mass storage device(s) 108 include various computer readable media, suchas magnetic tapes, magnetic disks, optical disks, solid-state memory(e.g., flash memory), and so forth. As shown in FIG. 1, a particularmass storage device is a hard disk drive 124. Various drives may also beincluded in mass storage device(s) 108 to enable reading from and/orwriting to the various computer readable media. Mass storage device(s)108 include removable media 126 and/or non-removable media.

I/O device(s) 110 include various devices that allow data and/or otherinformation to be input to or retrieved from computing device 100.Example I/O device(s) 110 include cursor control devices, keyboards,keypads, microphones, monitors or other display devices, speakers,printers, network interface cards, modems, lenses, CCDs or other imagecapture devices, and the like.

Display device 130 includes any type of device capable of displayinginformation to one or more users of computing device 100. Examples ofdisplay device 130 include a monitor, display terminal, video projectiondevice, and the like.

Interface(s) 106 include various interfaces that allow computing device100 to interact with other systems, devices, or computing environments.Example interface(s) 106 include any number of different networkinterfaces 120, such as interfaces to local area networks (LANs), widearea networks (WANs), wireless networks, and the Internet. Otherinterface(s) include user interface 118 and peripheral device interface122. The interface(s) 106 may also include one or more user interfaceelements like user interface 118. The interface(s) 106 may also includeone or more peripheral interfaces, such as interfaces for printers,pointing devices (mice, track pad, etc.), keyboards, and the like.

Bus 112 allows processor(s) 102, memory device(s) 104, interface(s) 106,mass storage device(s) 108, and I/O device(s) 110 to communicate withone another, as well as with other devices or components coupled to bus112. Bus 112 represents one or more of several types of bus structures,such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.

For purposes of illustration, programs and other executable programcomponents are shown herein as discrete blocks, although it isunderstood that such programs and components may reside at various timesin different storage components of computing device 100 and are executedby processor(s) 102. Alternatively, the systems and procedures describedherein can be implemented in hardware, or a combination of hardware,software, and/or firmware. For example, one or more application specificintegrated circuits (ASICs) can be programmed to carry out one or moreof the systems and procedures described herein.

FIG. 2 illustrates an example of a network environment 200 suitable forimplementing systems and methods described herein. The environment 200may include one or more merchant systems 202 a-202 b. Each merchantsystem 202 a-202 b may be embodied as a server farm or multiple remoteservers connected to one another by a network. A merchant system 202a-202 b may have one or more databases 204 a-204 b associated therewithto store information regarding online or in-store activities, or both.The merchant systems 202 a-202 b may be owned or controlled by the sameor different entities. Owners and employees may access the merchantsystems 202 a-202 b by means of one or more workstations 206 a-206 b.The workstations 206 a-206 b may be embodied as general purposecomputers, tablet computers, smart phones, terminals, or the like.

The merchant systems 202 a-202 b may connect to a network 208, which mayinclude some or all of a local area network (LAN), wide area network(WAN), virtual private network (VPN), the Internet, and other networks.

One or more point of sale (POS) devices 210 a-210 b may also be operablyconnected to the network 208 and have the capacity to communicate withone or more of the merchant systems 202 a-202 b. Each POS device 210a-210 b may be associated with a physical store. The store andcorresponding POS device 210 a-210 b may be owned or controlled by thesame entity owning or controlling one of the merchant systems 202 a-202b. In some embodiments, a POS 210 b is operably connected to a POS host212. The POS host 212 may interface with the POS 210 b to manage storetransactions at one or more stores. The POS may also be an automatedsystem, such as an automated teller machine (ATM) that is capable ofreceiving electronic and cash payments. As such, the POS, though oftenlocated in a store, may be located elsewhere. Accordingly, references to“in-store” payments at a POS may also be replaced by payment at an ATMor other facility, such as a bank or other financial or governmentalinstitution. The POS host 212 may likewise interface with one of themerchant systems 202 a-202 b to provide information regarding POStransactions to the merchant system.

A POS, according to any of the aforementioned implementations, may beoperable to scan barcodes. For purposes of this disclosure, referencesto barcodes and the scanning of barcodes may refer to a barcode receivedby email, multimedia messaging service (MMS) message, or other means.The barcode will then be reproduced by a customer on a printed page oron the screen of a mobile phone, tablet computer, or any otherelectronic device. Scanning of a barcode may be performed by scanning ascreen of any of the foregoing devices or by scanning a reproduction ofthe barcode on a printed page.

A user workstation 216 may also connect to the network 208. Theworkstation 216 may be embodied as a general purpose computer, tabletcomputer, smart phone, or the like. The user workstation 216 may host abrowser or other application enabling the ability to request and receiveinformation from the merchant systems 202 a-202 b as well as the abilityto transmit information to the merchant system 202 a-202 b, such as inthe form of web pages and other content as known in the art.

FIG. 3 illustrates an example of components that may be hosted by amerchant system 202 a-202 b. As noted above, a merchant system 202 a-202b may include one or more servers. Accordingly, the functionalityattributed to a component shown in FIG. 3 may likewise be implemented bya single server or shared between multiple servers. Similarly, a singleserver may implement all or part of the functionality of multiplecomponents.

A merchant system 202 a-202 b may include a catalog system 300, whichmay have a catalog database 302 associated therewith. The catalog system300 may store information regarding items for sale by the merchant. Thecatalog system 300 may list inventory for items offered for sale by themerchant. An order management system 304 may create orders for items inresponse to user requests and track the progress of orders. The ordermanagement system 304 may receive notifications from other components inorder to update the status of an order. The order management system 304may likewise transmit information and instructions to other componentsto facilitate payment and fulfillment of an order. An order database 306may be associated with the order management system and include recordsfor one or both of pending and concluded orders.

A web interface system 308 may provide an interface to a web browserexecuted on a client device. The web interface system 308 may enableonline browsing of items for sale by a customer, receive customerrequests to purchase items, receive payment information from customers,and perform other aspects of online commerce as known in the art. Theweb interface system 308 may have a web database 310 associatedtherewith. The web database 310 may include web pages, web applicationprogramming interfaces (APIs), scripts, and other data to facilitateconducting online transactions over a network by interfacing with acustomer browser. The web database 310 may additionally storeinformation regarding customer accounts and programs for managing theuser accounts.

One or more fulfillment systems 312 manage the actual retrieval of itemsfrom inventory and shipping of items to customers. The fulfillmentsystem 312 may receive instructions to ship items from the ordermanagement system 304. Each fulfillment system 312 may be associatedwith an actual fulfillment center that includes warehousing forinventory as well as personnel and equipment for packaging and shippingitems to customers. A fulfillment system 312 may therefore include anyand all computing resources and automated equipment to facilitate thesefunctions. Each fulfillment system 312 may have a database 314associated therewith that stores information about available inventoryand the status of orders to be fulfilled. In some embodiments, a singlecommon database 314 stores all information for multiple fulfillmentsystems 312.

A payment processing system 316 may interface with one or more financialinstitutions, check printing facilities, credit card companies, andother financial processing services or entities. The payment processingsystem 316 may receive user payments, issue refunds, or receivenotification of payments or refunds from other entities. The paymentprocessing system 316 may have a payment database 318 that may storeinformation regarding past and pending payments, refunds, sales taxinformation, and other financial activities.

A management information system 320 collects information regardingactivities of the other components and generates reports eitherautomatically or upon management request. The management informationsystem 320 may also monitor activities of other components and generatealerts based on analysis of these activities. The management informationsystem 320 may have a database 322 associated therewith for storinghistorical data regarding past activities of the components.

FIG. 4 illustrates examples of records that may be generated or accessedby the components shown in FIG. 3. For example, the order database 306may create and store order records 400 for pending orders and may retainthe order records 400 after an order has concluded. The order records400 may store information regarding an order such as a user identifier402, which identifies the customer associated with an order and shippinginformation 404 for the order. The shipping information 404 may beassociated with a user record corresponding to the user identifier 402,when this information is not included in the order record 400.

The order record 400 may additionally record item information 448 forthe order. The item information 448 may identify one or more itemsassociated with the order. Other item information may include a purchaseprice for an item, any discounts or coupons that apply to an item, andother item related information. The item information 406 may include anitem identifier corresponding to an item record stored in a catalogdatabase 302 or elsewhere.

The order record 400 may also include a shipping status 408 of theorder. This may indicate whether the item is in process at a fulfillmentcenter, waiting to be picked up by a carrier, in transit, arrived, or insome other stage of the shipping process.

The order record 400 may include a payment method 410 and payment status412. As described in great detail herein, orders may be paid for byusing conventional electronic payment (e.g., credit/debit card numbers)or by paying in cash at a point of sale (POS). Accordingly, the paymentmethod 410 indicates which of these methods a customer has selected. Asalso described in greater detail below, in a pay-with-cash purchase, thecustomer is given a grace period to pay on an order at a POS.Accordingly, the payment status 412 may indicate whether payment at aPOS has occurred.

An order record 400 may also have a refund preference 414 associatedtherewith. In a pay-with-cash order as described hereinbelow, a userpays for an order at a POS and therefore an electronic refund to acredit card may not be possible. Accordingly, the customer may choose toreceive refunds by receiving a check in the mail or by picking up cashat a POS. The refund preference 414 indicates which of these options thecustomer prefers. The refund preference 414 may also include a mailingaddress if a check is requested or identify an authorized pick-up personif cash at a POS is selected.

A refund status 416 may indicate the status of a refund; for example,whether a check has been mailed, payment has been picked up at a POS, anelectronic refund has been processed, or some other event relating to arefund has occurred. An order record may also store other informationrelating to an order, such as a store preference 418. The storepreference 418 may indicate a store selected by a customer to pay for apurchase or receive payment of a refund.

Some or all of the information associated with an order record 400 maybe retrieved from or linked to a user account database 420. The useraccount database 420 may be associated with users of an ecommercewebsite. Accordingly, the user account database 420 may be included inthe web database 310. The user account database 420 may include userrecords 422 for current and past customers of a merchant. The userrecords 422 may include user preferences that are independent of aparticular order or preferences that correspond with a customer's recentorder. In some embodiments, the data of the user record can be retrievedand edited by a customer independent of placement of an order. Userrecord data may also be edited in the course of an order.

The user record may include one or more of a user identifier 424,contact information 426, shipping information 426 and item information428, payment preferences 430 such as pay at POS or electronic payment asdescribed above, refund preferences 432 as described above, a preferredstore 434, pending orders 436 for the customer, pending refunds 438,order history 440, and finally authentication information 442 such as auser name and password. The pending orders 436, pending refunds 438, andorder history 440 may include links to corresponding order records 400.In some embodiments, some or all of this information may be maintainedin the order management database 306 or other database, and linked to auser record 422 by means of the user ID 424.

A catalog database 302 may store item records 444. An item record 444may store information such as an item ID 446 and item information 448such as a description, reviews, related items, and other information ofinterest to a customer. The item record 444 may additionally store apath 450 to the item in an item categorization hierarchy. Alternatively,the item record 444 may contain no reference to a hierarchy and ahierarchy definition may be stored elsewhere. The item record 444 mayalso indicate one or both of a current price 452 and a price history454. The price history 454 may record changes to the item price overtime. An item record 444 may also indicate eligibility 456 of the itemfor various payment methods. In particular, the eligibility 456 mayindicate whether a customer may choose to order the item online or payfor the item at a POS, as described in greater detail hereinbelow. Theeligibility 456 may also indicate a quantity of the item or otherrestrictions that can be purchased by a user using online ordering withPOS payment, such as described in greater detail hereinbelow.

The catalog database 302 may additionally include hierarchy data 458.The hierarchy data may define an item hierarchy 460, including classesand subclasses of items and assignments of particular items toparticular classes and subclasses. For example, the class power toolscould have a subclass of lawn equipment, and the subclass of lawnequipment could have its own subclass of lawnmowers. A particularlawnmower could then be an item assigned to this lawnmower subclass.

In some embodiments, eligibility of an item for online ordering with POSpayment may be specified according to the hierarchy. For example, eachclass and subclass definition may be defined as a node in a hierarchicaltree. Each node will have either descendent nodes or descendent items.Accordingly, defining the eligibility assigned to a node may be appliedto all descendent nodes and items for that node. The definitions of theeligibility of nodes may be stored as node eligibility data 462.Exceptions and other overrides to any node eligibility definitions maybe applied to specific descendent nodes and items. These overrides maybe stored as override data 464.

FIG. 5 illustrates a method 500 for processing an online transaction.The method 500 may be performed by a merchant system 202 a-202 b, POS,some other device owned or controlled by a merchant, or a combinationthereof. A request to purchase an item may be received 502, such as froma browser executing on a customer workstation 216. For the purposes ofthis application, communication with a costumer may be interpreted ascommunication with a device associated with the customer, such as thecustomer workstation 216, an email server, or other device accessed bythe customer. Specifically, messages to a customer may be transmitted toan open browser window or as an email, and messages from a customer maybe received as inputs to a browser window or as an email.

Shipping information may also be received 504 from the customer orretrieved from existing records for the customer or order. An estimatedarrival time may be calculated 506 for the item according to theshipping information. The arrival time may indicate an estimate of thetime required for the item to arrive at a shipping location, such as thetime it takes to locate the item at a fulfillment center, package theitem, and ship the item to the address specified in the shippinginformation for a selected shipping method.

A payment method for the customer may be received 508 for the customeror retrieved from an existing record for the customer or order. Examplesof payment methods include electronic payment (credit/debit card orother electronic account), a gift card or store credit card, or pay at aPOS (e.g., pay with cash in store). For the purposes of this disclosure,“pay with cash” refers to payment at a POS for an online transaction. Insome instances this option is designed to appeal to people who lackelectronic banking accounts and therefore may prefer cash as theirmethod of payment at the POS. However, the “pay with cash” option bymeans of payment at the POS in a store may also refer to payments at aPOS made using a credit or debit card, check, store credit card, orother electronic account. In some applications, “point of sale” mayrefer to the functional unit that processes payment for onlinetransactions. However, POS as used herein refers to a POS that iscapable of accepting physical tender of cash or check payment, as wellas electronic payment such as credit and debit cards. Such POS aretypically located in a store and may be operated by a cashier. A POS mayalso be implemented as an automated device. An ATM, for example, iscapable of interacting directly with a customer to receive payment.

If POS payment is not found 510 to be selected, the electronic paymentis processed 512, and confirmation of purchase may be transmitted 514 tothe customer. The calculated arrival estimate may also be transmitted516 to the customer and fulfillment of the order is authorized 518 orotherwise initiated. Authorization of fulfillment may includetransmitting order information such as one or more item identifiers andshipping information to a fulfillment center capable of packaging andshipping one or more items associated with the order.

If POS payment is found 510 to be selected then a “pay period” may beadded 520 to the calculated arrival estimate. The pay period is the timeperiod after which the order is made in which the customer must pay at aPOS before the order is automatically canceled due to expiration. Insome embodiments, the pay period includes an initial period plus a graceperiod. The initial period may be communicated to the customer whereasthe grace period is an additional time interval after the initial periodin which payment will be accepted if tendered at a POS.

The arrival estimate, as updated according to the pay period, may betransmitted 522 to the customer. Purchase terms, including a purchaseprice, the pay period, and any other purchase terms may be transmitted524 to the customer. The pay period may be communicated as the dateand/or time at which payment must be received at a POS before the orderis automatically canceled.

The purchase terms may also include a barcode, order number, or otherinformation used by the user to identify the order at a POS in a store.In some embodiments, a customer may specify a “payment person”indicating who is authorized to tender payment.

To pay for the order, a user may present one or more items ofinformation to identify the online order. These may include a barcode,an order identifier, a customer phone number, customer name, or otheridentifying information. Upon receiving this information, a cashier mayinput the information to a POS 210 a-210 b. Alternatively, a user mayenter the information at a self-checkout POS. In the case of a barcode,the POS may include a scanner and retrieve information by scanning thebarcode.

Upon receiving this information, the POS may transmit the information toa merchant system 202 a-202 b or other device performing the method 500.The order identification information is received 526. The ordercorresponding to the order identification information may be evaluated528 to determine whether the pay period has expired. If the payer periodis found 528 to have expired, the POS may be notified 530 of expiry.

If the payer period is found 528 not to have expired, then orderinformation may be transmitted 532 to the POS. In some embodiments, themethods disclosed herein may be performed in a batch processing scheme.For example, pending orders may be periodically evaluated to determinewhether the pay period has expired. If so, then the order may be flaggedas expired. Accordingly, evaluating 528 whether payment acknowledgmentwas received in the expiry period may include evaluating this flag.

The order information transmitted 532 may include a purchase price. Theorder information may also include an identity of an authorized paymentperson for the order. The POS may then receive tender of payment of thepurchase price, which may include cash, check, or electronic payment.The POS may then transmit acknowledgment of payment to the merchantsystem 202 a-202 b. The merchant system 202 a-202 b receives 534 theacknowledgment of payment from the POS. In some embodiments, uponreceiving acknowledgment of payment, the merchant system 202 a-202 btransmits an email or other message to the customer that acknowledgespayment.

The updated arrival estimate calculated at step 520 may then again beupdated 536 based on when acknowledgment of payment was received 534from the POS. This may include calculating an expected arrival datebased on initiation of fulfillment of the order as of the dayacknowledgment of payment was received. This may include taking intoaccount delays, which may occur due to backups at a selected fulfillmentcenter, time required to retrieve and package the item(s), time requiredfor a carrier to pick up the packaged item(s), estimated time in transitto the customer's specified shipping address, and any other factorsrelevant to variations in shipping time. The updated arrival estimatemay then be transmitted 538 to the customer, such as by means of anemail. Fulfillment of the order may then be authorized 540 or otherwiseinitiated. This may include transmitting order information, such as theitem(s) of the order and the customer's shipping information to afulfillment center.

FIG. 6 illustrates another method 600 for processing an onlinetransaction. The method 600 may be performed along with the method 500and other methods described herein. The method 600 may be performed by amerchant system 202 a-202 b, POS, some other computing device, or acombination thereof. The method 600, as in the method 400, may includereceiving 602 a request to purchase one or more items from a customerand receiving or retrieving 604 shipping information from a customer.

A payment method may also be received or retrieved 606 as describedabove. If the payment method is found 608 not to be a POS paymentmethod, as described above, then electronic payment is processed 610 asknown in the art. The shipping information may be evaluated 612 todetermine an appropriate fulfillment centers and the order may beenqueued 614 for assignment to a fulfillment center. Orders may beprocessed on a first-in, first-out basis according to when they wereadded to the queue. Each order may be assigned 616 to a fulfillmentcenter based on whether the fulfillment center has the order item(s) instock, proximity of the fulfillment center to the shipping address, andbacklog of unfulfilled orders assigned to the fulfillment center. Once afulfillment center is selected 616, authorization to fulfill the ordermay be transmitted 618 to the fulfillment center along with orderinformation, such as item identifiers and the shipping information.

If POS payment is found 608 to have been selected, purchase terms suchas a payment deadline, purchase price, and any other relevant terms maybe transmitted 620 to the customer. Order information such as a barcode,order identifier, or other information used by the customer when payingat a POS may also be transmitted to the customer. If acknowledgment ofpayment is found 622 to have been received from the POS before thedeadline, then the method proceeds to perform one or more of steps612-618 for the order. If not, then the order is canceled 624, which mayinclude notifying the customer of cancellation.

FIG. 7 illustrates another method 700 for processing an onlinetransaction. The method 700 may be performed along with some or all ofthe methods described herein. The method 700 may be performed by themerchant system 202 a-202 b, a POS, some other computing device, or acombination thereof. The method 700 may include receiving 702 a requestto purchase one or more items from a customer and receiving 704 from acustomer, or retrieving, shipping information.

The method 700 may include evaluating 706 whether the customer hasrequested to apply store credit. If so, then store credit informationmay be received 708, such as by receiving a code or other identifier ofan account or gift card. Some or all of credit associated with thesupplied information may be applied 710 to the purchase price for theorder. If the complete purchase price is applied in this manner, nofurther processing may be performed other than to authorize fulfillmentof the order.

A payment method selection may also be received 712 or retrieved for theorder. If the method of payment is found 714 to not be a POS paymentmethod, then electronic payment may be processed 716 and fulfillmentauthorized 718 or otherwise initiated.

If the selected payment method is found 714 to be a POS payment method,then purchase terms, including such information as an order identifier,a payment deadline, purchase price, and/or other relevant informationmay be transmitted 720 to the customer. If acknowledgment of payment ofthe balance due is found 722 to have been received from a POS such as anin-store POS, prior to expiration of the pay period, which may include agrace period, then fulfillment of the order is authorized or otherwiseinitiated.

If acknowledgment of payment of any balance is not found 722 to havebeen received prior to expiration of the pay period, then the order maybe canceled 724 and any store credit applied to the order may berestored 726 to the account or card from which it was drawn.Alternatively, restoration 726 may include mailing a store credit cardto the customer or some other means of restoring the store credit to thecustomer. In some embodiments, restoration may include indicating that acard is available for pick up at a store and authorizing transfer ofsuch a card upon request of the customer and furnishing ofauthenticating information by the customer. In some embodiments, acustomer's choice of one of the aforementioned methods or another refundmethod for store credit may be received and the refund will be madeaccordingly.

FIG. 8 illustrates another method 800 for processing an onlinetransaction. The method 800 may be performed along with some or all ofthe methods described herein. The method 800 may be performed by themerchant system 202 a-202 b, POS, some other computing device, or acombination thereof. The method 800 may include receiving 802 a requestto purchase one or more items from a customer and receiving 804 from acustomer or retrieving shipping information.

A customer's choice of payment method may also be received or retrieved806. If the chosen payment method is not found 808 to be a POS payment,then electronic payment may be processed 810 as known in the art andfulfillment may be authorized 812 or otherwise initiated.

If POS payment is found 808 to be the chosen method, then the method 800may include evaluating 814 the shipping information for the order andretrieving 816 from a database store locations and participation statusof the stores. Participation status indicates whether the store iscapable or otherwise authorized to receive POS payments for onlineorders. Stores adjacent to the customer (based on the shipping addressor other address associated with the customer) and stores that arecapable or otherwise authorized to receive POS payments for onlinetransactions may be identified 818. The payment deadline, purchaseprice, and other information may be transmitted 820 to the customer. Theidentified adjacent participating stores may also be transmitted 820 tothe user to enable the user to locate a store at which to pay for theorder.

As with other methods, if acknowledgment of payment of the purchaseprice is found 822 to have been received from a POS, then fulfillment isauthorized 812 or otherwise initiated. If not, the order may be canceled824.

FIG. 9 illustrates a method 900 for presenting store locations to acustomer. While browsing for items a customer may place items in avirtual shopping cart as known in the art. At checkout, a customer maywish to pay at a POS according to the methods described herein. Acustomer's payment method preference may be input at some point prior tocheckout or may be retrieved from records for the customer. In eithercase, at some point during checkout a user may want to know whether astore is located nearby. This may be due to a desire to use asite-to-store shipping choice, a desire to use a POS payment method, ora desire to locate an item at a nearby store.

In any case, shipping information, or other information indicating acustomer's location may be received 902 or otherwise retrieved. Apayment method selection may also be received 904 or retrieved. Arequest to show adjacent stores may also be received 906, for any of thereasons noted above. A list of stores may be retrieved and filtered 910according to one or both of the shipping (or other geographic)information and the payment method. Filtering according to shippinginformation may include omitting stores outside a certain proximity tothe shipping location. Filtering according to payment method may includeomitting stores that do not participate in the selected payment method.A list or map illustrating stores remaining following the filteringoperation may be transmitted 912 for display to the customer. Where oneor both of shipping information and a payment method selection are notavailable or have not been made by the customer, the correspondingfiltering step may be omitted in some embodiments.

FIG. 10 illustrates a method 1000 for processing payments for onlinetransactions at a POS. The method steps of 1000 are attributed to thePOS in the discussion below. However, the method steps may be performedby one or both of a POS and a POS host corresponding to the POS.

In particular, the method 1000 is particularly useful in instances wherea POS or a POS host is temporarily not able to communicate with amerchant system 202 a-202 b or some component thereof, such as the ordermanagement system 304. The method 1000 may include receiving 1002 arequest to process a POS payment for an online payment at a POS. Thismay be performed by a cashier or a user at a self-checkout POS. The POSmay evaluate 1004 whether a merchant system 202 a-202 b is offline. Ifnot, then the POS may interactively process 1006 the order as in thevarious methods described herein. This may include the POS transmittingan order identifier to the merchant system 202 a-202 b, receiving orderinformation from the merchant system 202 a-202 b, and transmittingacknowledgment of payment to the merchant system 202 a-202 b aftertender of payment is detected or otherwise verified.

If the merchant system is found 1004 to be offline, then a batchprocessing method according to the following steps may be executed. Asnoted above, in some methods an order identifier may be used by the POSto request order information from a merchant server 202 a-202 b. Wherethe merchant server 202 a-202 b is not available, a customer printout ofthe purchase price may be used to provisionally determine the purchaseprice for the order. Alternatively, a database of pending orders forwhich POS payment has been selected may be pushed to a POS periodicallysuch that order information can be retrieved without communication withthe merchant server.

Tender of payment at the POS may be received 1008. This may includereceiving an electronic payment from a credit or debit card, detectingtender of cash to an automated bill and coin collector, receiving aninput from a cashier indicating receipt of payment, or some otherdetection of tender.

The POS may add 1010 order information received from the customer, suchas an order identifier, and an amount of tender of payment to a batchfile. The batch file may accumulate payment information for tenders ofpayment for online orders while communication with the merchant server202 a-202 b is unavailable.

Once communication with the merchant server 202 a-202 b is restored, thePOS may reconcile the batch of received payments with the merchantserver. Accordingly, the method 1000 may include detecting 1012availability of the merchant system 202 a-202 b. This may beaccomplished by the merchant server 202 a-202 b contacting to the POSupon restoration of communication. Alternatively, the POS that has abatch file with unreconciled payments in a batch file may periodicallyquery the merchant server to determine if the merchant server 202 a-202b is online until a response is detected 1012.

The POS may transmit 1014 the batch file to the merchant system 202a-202 b for processing by the merchant system 202 a-202 b. The merchantsystem 202 a may then evaluate the batch 1016 relative to pending ordershaving POS payment as the payment method.

The method 1000 may include detecting 1018 duplicate payments. Inasmuchas communication with the merchant system 202 a-202 b was not possibleat the time of payment, it is possible that multiple payments could havebeen received since the POS was unable to determine whether an order hasalready been paid. Accordingly, multiple payments associated with thesame order identifier may be detected 1018.

Payments recorded in the batch file may also be evaluated with respectto order records to determine 1020 whether order payments have beenreceived for expired orders. Payments recorded in the batch file mayalso be evaluated with respect to order records to detect 1022 paymentsfor unavailable items.

If for any reason an order cannot be fulfilled due to one or more ofexpiry and unavailability of the item(s) of the order, then appropriaterefunds may be authorized 1024 and processed 1026. If an order can befulfilled, then fulfillment of the order may be authorized 1028 orotherwise initiated. If an order for which payment is noted in the batchfile as expired and fulfillment of the order is still possible (e.g.,inventory is available or otherwise sufficiently abundant) in someembodiments, fulfillment of the order may be authorized 1028notwithstanding expiry.

Refunds may also be authorized 1024 corresponding to a price reductionfor one or more items in an order, where the price reduction occurredbetween the time an order is created and payment was received at thePOS, as described herein below with respect to FIGS. 18-20. In someembodiments, refunds may also be authorized corresponding to a pricereduction that occurred between the time an order is created and thetime the batch is received by the merchant system 202 a-202 b.

FIG. 11 illustrates a method 1100 for processing mixed purchases ofonline orders and in-store selections. The method steps described beloware attributed to a POS. However, the method steps may also be performedusing a POS, POS host, a merchant system 202 a-202 b, or a combinationof these. A POS receives item information 1102. This may includescanning a barcode affixed to the item or printed out by the customerfor an online order. For online orders, a customer's order may also beretrieved from a merchant system 202 a-202 b by other means, such asusing the customer's name, phone number, or other identifyinginformation. If the item is found 1104 to be an online order, then theorder information may be retrieved 1108 such as using a web applicationprogramming interface (API) or other means, to retrieve orderinformation such as one or more of a purchase price, item identifier(s),and an identity of an authorized pick up person. If the item is notfound 1104 to be an online order, then item information may be retrieved1106 by the POS from a POS host or other system for managing a storeinventory and checkout process. The item information retrieved mayinclude one or more of an item identifier and a purchase price.

Item information may be received 1102 and evaluated 1104 untilinformation for the last item of the customer's purchase is found 1110to be received. An aggregate price for all in-store selections andonline orders may then be aggregated 1112. This may include calculatingany tax due and applying any discounts or coupons the customer has used.Tender of payment is received 1114 by the POS by detecting payment bycash or check or by processing electronic payment such as a store creditcard or a debit or credit card. The POS then informs 1116 the merchantsystem 202 a-202 b of payment for any online orders in the purchase,such as by means of a web API provided by the merchant system 202 a-202b. Likewise, inventory and accounts associated with the store may beupdated 1118 to reflect purchases of in-store items. This may beaccomplished by notifying a POS host of details of the transaction.

FIG. 12 illustrates another method 1200 for processing mixed purchasesof online and in-store items. As in the method 1100, the steps describedin the method 1200 as being performed by a POS may also be performed byone or more of a POS, POS host, and merchant system 202 a-202 b. As forthe method 1100, item information may be received 1102, such as byscanning a barcode affixed to a product or by having the customer printout the information for an online order. Item information may also bereceived for an online order by looking up a customer's order based onthe customer's name or other identifying information.

If the order is found 1204 to be an online order then order informationmay be retrieved 1206 from the merchant system 202 a-202 b, such as byusing a web API. The order information retrieved may include one or moreitem identifiers and a purchase price. If an item corresponding to theonline order is found 1208 to be available in the store, a prompt may bedisplayed 1210 to a cashier or customer to inform the customer that theitem is available in-store. If the POS finds 1212 that the customer haschosen to pick up an item from the store, then the POS may inform themerchant system 202 a-202 b of fulfillment of the order upon payment,such as by means of a web API. The POS may detect a user choice to pickup an item from an online order by detecting scanning of a barcode forthe item, or by a cashier or customer providing an input which willindicate pick up of the item(s) for the online order.

As for the method 1100, if the item is found 1204 to be an in-storepurchase, item information is retrieved 1216 from a store system, suchas a POS host. When the last item is found 1218 to have been received,an aggregate price is calculated 1220, which may include calculating anytax and applying any applicable coupons or discounts. Tender of paymentis detected 1222 by the POS, and the POS informs the merchant system 202a-202 b, such as by means of a web API, of payment for any onlineorders. Likewise, store inventory and accounts are updated to reflectpurchases of in-store items, including items from online orders that thecustomer chose to pick up. This may include notifying a POS host ofin-store purchases and tender of payment.

FIG. 13 illustrates a method 1300 for avoiding receiving duplicatepayments for online orders at a POS. An order identifier may be received1302 at a POS according to any of the ways described in previousmethods. The POS then requests order information 1304 for the orderidentifier, such as one or more of a purchase price, order status, itemidentifier, or other information. The merchant system 202 a-202 breceives 1306 the request and evaluates 1308 the status of the orderassociated with the order identifier. If the status is found 1308 toindicate the order is “awaiting payment,” then the requested orderinformation may be transmitted 1310 to the POS and the status for theorder may be changed 1312 to indicate “payment pending.” An identifierof the POS that submitted the request, or “cart ID” may also beassociated with the order.

Upon receiving 1314 the order information, the POS may receive payment.If payment is found 1316 to have been received prior to closing of thePOS transaction, then the merchant system 202 a-202 b may be notifiedand the status of the order is changed 1318 to indicate that payment hasbeen made. If payment is not found 1316 to have been received prior toclosing the transaction, the POS may notify the merchant system 202a-202 b, which may then change 1320 the status of the order to indicatethat it is awaiting payment.

If the status of the order is not found 1308 to indicate awaitingpayment, then the method may include evaluating 1322 whether the orderstatus indicates payment pending. If so, then the “cart ID” associatedwith the order may be evaluated 1324. If it is the same as the “cart ID”received from the POS in the current iteration of the method 1300, thisindicates that multiple requests were received from the same POS duringthe same transaction. The POS may therefore be notified 1326 of theduplicate and the POS may then cancel 1328 the duplicate request fororder information.

In case the status is not found 1322 to indicate payment pending or the“cart ID” for order is not found 1324 to match the “cart ID” for thecurrent request being processed in the current iteration of the method1300, an error message may be returned 1330 to the POS and the POS maythen cancel the request for order information and may not proceed withreceiving payment for the online order.

A log of requests may be kept for troubleshooting purposes. In someembodiments, the case where an order status is not being paid, awaitingpayment, or payment pending may be impossible to reach, as theseparticular order statuses do not need to be dealt with. In otherembodiments, the status may revert to awaiting payment within a timeperiod after this status is reached. Alternatively, an alert may betransmitted to an employee, who may then manually reset the status afterviewing a log of activity for the order. In some embodiments, eachrequest for information for an order or to update the status of an orderreceived from a POS may be logged in a record associated with the orderto enable resolution of error conditions.

Another potential error condition is where a POS for some reason causesthe status to change to “payment pending” and then hangs or losescommunication with the merchant system 202 a-202 b before notificationof payment or cancellation without payment can be transmitted to themerchant system 202 a-202 b. In such instances, the status may revert to“awaiting payment” after a timeout period. Alternatively, the order mayremain in this state until a customer service representative or otheremployee reviews the transaction history and reverts the status toawaiting payment or paid, based on the present circumstances.

FIG. 14 illustrates a method 1400 for processing payments for layawayitems as well as online orders for which POS payment was selected. Insome embodiments, upon placing an order, a user may specify a form ofelectronic payment, POS payment, or layaway. For layaway, a customer maybe charged a fee and be permitted to pay for an item in installments. Insome embodiments, these installments may be made electronically onlineor at a POS. In either case, an order is created, but adding the orderto a queue for assignment to a fulfillment center is delayed untilcomplete payment is received.

The steps of the method 1400 may be distributed among some or all of aPOS, POS host, and a merchant system 202 a-202 b. An order ID may bereceived 1402, such as by inputting the order ID to a POS according toany of the methods described hereinabove. Receiving 1402 the order IDmay include receiving the order ID by a merchant system 202 a-202 b froma POS. Order information corresponding to the order ID may be retrieved1404, which may include transmitting the order information to a POS. Ifthe order is found 1406 to be expired, the transaction may be canceled1408. This may include notifying the POS of expiration by the merchantsystem 202 a-202 b, and canceling or otherwise voiding the transactioninitiated at the POS with respect to the online order.

If the order is not found 1406 to be expired, then payment may bereceived 1410. This may include receiving tender of payment at the POSin one of multiple forms already mentioned herein and transmittingnotice of payment from the POS to the merchant system 202 a-202 b.

If the order is found 1412 to be paid in full as a result of thepayment, then fulfillment of the order may be authorized 1414 orotherwise initiated. If the order is not found 1412 to be paid in full,i.e., the payment is a partial payment, then the payment may be applied1416 to the balance due for the order.

In some embodiments, partial payments will not be accepted by the POSfor a non-layaway order (e.g., a pay at POS order). However, in someembodiments, partial payments for non-layaway orders may be received bythe POS. In one embodiment, if a partial payment is found 1418 to havebeen received for a POS payment order that is not layaway, the order isconverted 1420 to a layaway order. A layaway fee, accompanied bycustomer notification, may be added 1422 to the balance due for theorder in embodiments such that a fee is ordinarily applied to layawayorders.

In the cases of both partial payment for layaway and non-layaway orders,a payment schedule may be updated 1424 according to the partial payment.For example, if the customer pays more than a single installment for alayaway order, the amount and timing of further payments may beadjusted. For a non-layaway order, a payment schedule taking intoaccount the partial payment may be generated and transmitted orotherwise communicated to the customer.

In an alternative embodiment, if a partial payment is received for anon-layaway order for which the POS payment method has been selectedduring the expiry period, the order is not converted to a layaway order.In some embodiments, if full payment is not received by the end of theexpiry period, the order is then converted to a layaway order and apayment schedule may be generated. In addition, fees may be assessed andcustomers may be notified. In other embodiments, the order is simplycanceled and a refund of the partial payment is initiated. In someembodiments, a user may specify at the time of placing the order whichof the foregoing methods will be used in response to a partial payment.

FIG. 15 illustrates a method 1500 for processing refunds for onlineorders for which a POS payment method has been selected and processedaccording to any of the methods described hereinabove. The method 1500may include receiving 1502 a refund trigger. Various triggers may bereceived. Examples of triggers include detecting unavailability of anitem after a customer has paid for the item at a POS but prior toshipment, receiving a customer request to cancel an order after payment,and failure of a customer to provide full payment after making a partialpayment by means of a store credit card or a partial payment at a POS.Other refund triggers include, but are not limited to, detecting anoverpayment, and detecting that payment has already been received.

In instances where a product has been shipped to a customer, a refundmay be triggered following both the receipt of a request for a refundand the receipt of the returned product from the customer. As known inthe art, packaging, labeling, and prepaid shipping labels may be mailedto the customer in response to a request for a refund. A refund may thenbe triggered when an input is received indicating that the returnedproduct has been received by the merchant.

Following receipt of a refund trigger, the method 1500 may includeevaluating 1504 whether the order for which a refund has been triggeredwas paid for at a POS. If not, an electronic refund may be applied 1506electronically, such as by electronically crediting the credit or debitcard used to pay for the purchase.

If the order was paid for at a POS, then a refund preference may bereceived or retrieved 1508. In some instances, a customer may specify arefund preference in the customer's account or at the time of orderplacement. In other instances, a refund preference may be specified atthe time a refund is requested. In some embodiments, a customer may beprompted to specify a refund preference and the customer preference maybe received after a refund trigger is received 1502.

In some embodiments, where no refund preference has been specified, therefund may be processed by initiating mailing of a check to a knownaddress for the customer. For example, if a refund preference has notbeen specified or otherwise received 1508 within a configurable numberof hours after the refund trigger has been received 1502, the refund maybe processed as if the customer requested mailing of a check.

If the customer preference is found 1510 to indicate payment at a POS,an identifier for a pick-up person may be received or retrieved 1512. Asfor the refund preference, the pick-up person ID may be stored in thecustomer's account, specified at the time the order is placed, orreceived in response to prompting at the time of the refund trigger orafter the refund trigger. Refund instructions may also be transmitted1514 to the customer. The refund instructions may include barcode and/ororder identifier. The refund instructions may also identify theauthorized pick-up person. In some embodiments, the refund instructionsmay indicate the location of one or more stores at which a refund may bereceived, such as described in FIG. 8 or 9.

A customer may then go to a store and present at the POS the barcode,order identification number, or some other information to identify thecustomer or order. The barcode may be scanned or any other informationmay be received by the POS and transmitted to the merchant system 202a-202 b. The merchant system 202 a-202 b may receive 1516 theinformation and use it to look up 1518 the order. This may includetransmitting data obtained from the barcode or otherwise received to themerchant system 202 a-202 b, which then locates the corresponding orderinformation and returns it to the POS. The order information transmittedto the POS may include an identity for a pick-up person and a refundamount.

The identity of the person attempting to obtain the refund may then beverified 1520. This may include receiving an input from a cashier at aPOS affirming the identity of the pick-up person following inspection ofphoto ID provided by the person. Verification of the identity may alsoinclude receiving a personal identification number (PIN) or passwordassigned to or chosen by a customer for purposes of verification. If theidentity of the pick-up person corresponds to the authorized pick-upperson designated by the customer, then refund is authorized 1522. ThePOS may then output money or instruct a cashier to refund the money.Upon detection of tender of the refund, the POS may transmit notice ofthe refund to the merchant system 202 a-202 b, which receives 1524 thenotice and records the fact that a refund was given, such as in theorder record for the order.

If a “cash in store” refund is not found 1510 to have been requested,then a name and/or address for a payee may be received or retrieved 1526for the order. As for other refund preferences, the payee name andaddress may be stored in the customer's account, specified at the timethe order is placed, or received in response to prompting at the time ofthe refund trigger or after the refund trigger. In some embodiments, thepayee may be constrained to be identical to the customer who placed theorder or the person who paid for the order at a POS.

A request for a check 1528 may be transmitted to an entity authorizedand capable of issuing checks such as a payment processing system 316 asdescribed above, a financial institution, or other entity. The entity towhich the request was made may transmit verification that a check wasmailed and this verification may be received 1530 by the ordermanagement system, which notes this fact such as in the order record forthe order.

FIG. 16 illustrates another method 1600 for processing refunds fororders for which a POS payment method has been selected and processedaccording to any of the methods described hereinabove. The method 1600may include receiving 1602 a refund trigger. Various triggers may bereceived. Examples of triggers include detecting unavailability of anitem after a customer has paid for the item at a POS but prior toshipment, receiving a customer request to cancel an order after payment,and failure of a customer to provide full payment after making a partialpayment by means of a store credit card or a partial payment at a POS.

In instances where a product has been shipped to a customer, a refundmay be triggered following the receipt of a request for a refund and thereceipt of the returned product from the customer. As known in the art,packaging, labeling, and prepaid shipping labels may be mailed to thecustomer in response to a request for a refund. A refund may then betriggered after the returned product is received.

Following receipt of a refund trigger, the method 1600 may includeevaluating 1604 whether the order for which a refund has been triggeredwas paid for at a POS. If not, an electronic refund may be applied 1606electronically, such as by electronically crediting a credit or debitcard.

If the order was paid for at a POS, then a refund preference may bereceived or retrieved 1608. In some instances, a customer may specify arefund preference in the customer account or at the time of orderplacement. In other instances, a refund preference may be specified atthe time a refund is requested. In some embodiments, a customer may beprompted to specify a refund preference and the customer preference maybe received after a refund trigger is received 1602.

If the customer preference is found 1610 to indicate payment at a POS,an identifier for a pick-up person may be received or retrieved 1612. Aswith the refund preference, the pick-up person ID may be stored in thecustomer's account, specified at the time the order is placed, orreceived in response to prompting at the time of the refund trigger orafter the refund trigger. Refund instructions may also be transmitted1614 to the customer. The refund instructions may include barcode and/ororder identifier. The refund instructions may also identify theauthorized pick-up person. In some embodiments, the refund instructionsmay indicate the location of one or more stores at which a refund may bereceived.

A customer may then go to a store and present at the POS the barcode,order identification number, or some other information to identify thecustomer or order. The barcode may be scanned or any other informationmay be received 1616 from the POS by the merchant system 202 a-202 b andused to look up 1618 the order. This may include transmitting dataobtained from the barcode or otherwise received by the merchant system202 a-202 b, which then locates the corresponding order information andreturns it to the POS.

The method 1600 may include evaluating 1620 whether a refund is due.This may include evaluating an order record associated with the order bythe merchant system 202 a-202 b to determine whether a refund haspreviously been issued or whether any payment has actually been made onthe order. If a refund is not found 1620 to be due, then a denial of therefund may be transmitted 1622 to the POS or otherwise transmitted tothe customer.

If a refund is due, the method 1600 may include evaluating 1624 whetherthe order is locked. A locked order may indicate that a refund is inprocess at another POS. If the order is found 1624 to be locked, thenstep 1622 may be performed. Otherwise, the transaction is locked 1626.Locking may include setting a flag in an order record indicating that itis locked. A refund may be authorized 1628. This may includecommunicating authorization to the POS. A cash refund, or other type ofrefund, may then be issued to the customer either automatically or bythe cashier. The cashier may input to the POS an indication that arefund has been given. The POS may transmit notice of the refund to themerchant system 202 a-202 b. The merchant system then receives 1630 thenotice of refund and may record this fact, such as in the order recordassociated with the order.

In some embodiments, if a refund is not actually issued after an orderis locked 1626, the lock may be released without indicating that arefund was given. In some embodiments, the POS may provide notice to themerchant system that the transaction was canceled without an actualrefund given. Upon receiving such a notification, the merchant system202 a-202 b may release the lock. In some embodiments, if a notice ofrefund is not received in some interval, such as a number of hours, thenthe lock may be released. Other criteria may also be used to release thelock if notice of refund is not received.

If a “cash in store” refund is not found 1610 to have been requested,then a name and/or address for a payee may be received or retrieved 1632for the order. As for other refund preferences, the payee name andaddress may be stored in the customer's account, specified at the timethe order is placed, or received in response to prompting at the time ofthe refund trigger or after the refund trigger. In some embodiments, thepayee may be constrained to be identical to the customer who placed theorder or the person who paid for the order at a POS. A request for acheck 1634 may be transmitted to an entity authorized and capable ofissuing checks such as a payment processing system 316 as describedabove, a financial institution, or other entity. The entity to which therequest was made may transmit verification that a check was mailed andthis verification may be received 1636 by the order management system,which notes this fact such as in the order record for the order.

FIG. 17 illustrates a method 1700 for processing a refund for an orderin which all or part of the purchase price for an online transaction ispaid using a store credit card such as a gift card. The method 1700 mayinclude receiving 1702 a cancellation request. The cancellation requestmay include any of the refund triggers listed above with respect toFIGS. 16 and 17.

The method 1700 may include evaluating 1704 whether store credit, suchas a store credit card or gift card, was used to pay for all or part ofthe purchase price for the order. If so, then the portion of thepurchase price paid with store credit may be refunded 1706 to the storecredit account from which it was originally drawn, or otherwise restoredin the form of store credit. Notice of this refund and of the amount ofstore credit may also be transmitted to the customer.

Regardless of whether store credit was used, the method 1700 may includeevaluating 1708 whether a POS payment method was used to pay for theorder, such as the POS payment methods described herein. This mayinclude evaluating the order record associated with the cancellationrequest. If a POS payment method was not used, then electronic refundmay be processed 1710 as known in the art for the balance due on theorder after any amount paid in store credit has been refunded 1706. Thetransaction may also be canceled 1712 such that the order will not befulfilled, if it has not yet been fulfilled.

If a POS payment method is found 1708 to have been used, then the method1700 may include evaluating 1714 whether the balance of the purchaseprice was actually paid at a POS. This may include evaluating whetheracknowledgment or notice of payment has been received from a POS, asrecorded in an order record associated with the order. If not, then theorder may be canceled 1712, which may include noting cancellation in theorder record for the order. If some or all of the balance has been paidthen a refund may be processed 1716. This may include processing 1716the refund according to methods described in one or both of FIGS. 15 and16.

FIG. 18 illustrates a method 1800 for responding to price changes foritems associated with online orders for which a POS payment method isselected. The method 1800 may be executed by one or more of the merchantsystem 202 a-202 b, POS, and POS host. The method 1800 may includesetting up 1802 an online order with POS payment as the selected paymentmethod, such as according to the methods described herein. Setting up1802 an order may include executing some or all of the steps of theforegoing methods. For example, an order may be set up by receiving atleast one item selection, receiving or retrieving a payment methodselection, and receiving or retrieving shipping information. As alreadynoted, the method 1800 is useful for online orders for which payment ata POS is the selected payment method.

The method may include receiving 1804 a request for order informationfrom a POS. As noted above, a request for order information may includean order identifier and may be generated by the POS in response to inputof the order identifier at the POS when the customers attempts to tenderpayment at a POS in a store. An order corresponding to the orderidentifier may be evaluated 1806 to determine if the order has expiredbecause the deadline for providing payment has passed. If so, then thePOS and/or customer may be notified 1808 of expiry. If not, then themethod 1800 may include evaluating 1810 whether a price change for anyitems associated with the order has occurred since the order was set up1802. If so, then the purchase price for the order may be reduced 1812to the current price. In either case, the order information with thecurrent price may be transmitted 1814 to the POS. Upon receiving 1816acknowledgment of payment of the purchase price, fulfillment of theorder may be authorized 1818 or otherwise initiated.

FIG. 19 illustrates another method 1900 for adjusting the price for anorder in which the POS payment method described herein has been selectedby a customer. The method 1900 may be performed by one or more of amerchant system 202 a-202 b, POS, POS host, or other component. Themethod 1900 may include updating 1902 a catalog of items offered forsale by means of a web site. This may include any type of updateoperation such as adding items, changing item descriptions, or the like.In particular, updating 1902 may include updating the price for items ina catalog. Both price increases and decreases may be performed.

The remaining steps of the method 1900 may be performed after eachcatalog update, or each catalog update in which a price decrease occurs.In some embodiments, some or all of the remaining steps of the method1900 may be performed as part of the catalog update process 1902, suchas by the same script or software module. In some embodiments, some orall of the remaining steps of the method 1900 may be performed prior tochanges to the catalog becoming effective.

The method 1900 may include retrieving 1904 or otherwise receiving 1904pending online orders for which POS payment is the selected paymentmethod. The orders retrieved 1904 may include orders with POS paymentfor which the order has been created but acknowledgment of payment hasnot yet been received from the POS.

Price changes between the purchase price of items as recorded in anorder and the updated prices of the catalog may be identified 1906 andthe purchase price for these items in the pending orders may be updated1908 to reflect the current price. In some embodiments, all changes tothe purchase price for items in an order may be recorded in a pricechange history for the order. This recording may be used to preventduplicate price reductions. Notice of changes in price to pending ordersmay be transmitted 1910 to the customers associated with these orders.

Upon checkout, a customer may, in accordance with other methodsdescribed herein, provide information identifying the order or thecustomer, which the POS then uses to request order information. Themerchant system receives 1912 the request for order information andtransmits 1914 to the POS the current order information, including thecurrent purchase price as updated 1908 according to any price changes.The POS then receives the information and receives tender of payment ofthe current purchase price. The POS then transmits acknowledgment ofpayment to the merchant system 202 a-202 b. The acknowledgment ofpayment is received 1916 and, in response, fulfillment of the order isauthorized 1918 or otherwise initiated.

FIG. 20 illustrates another method 2000 for adjusting the price for anorder for which the POS payment method described herein has beenselected by a customer. The method 2000 may be performed by one or moreof a merchant system 202 a-202 b, POS, POS host, or other component. Themethod 2000 may include updating 2002 a catalog of items offered forsale by means of a web site. This may include any type of updateoperation such as adding items, changing item descriptions, or the like.In particular, updating 2002 may include updating the price for items ina catalog. Both price increases and decreases may be performed. Theremaining steps of the method 2000 may be performed after each catalogupdate. In some embodiments, some or all of the remaining steps of themethod 2000 may be performed as part of the catalog update process 2002,such as by the same script or software module. In some embodiments, someor all of the remaining steps of the method 2000 may be performed priorto changes to the catalog becoming effective.

The method 2000 may include retrieving 2004 or otherwise receiving 2004pending online orders for which POS payment is the selected paymentmethod. The orders retrieved 2004 may include orders with POS paymentfor which the order has been created but acknowledgment of payment hasnot yet been received from the POS. In the method 2000, pending ordersmay additionally include retrieving orders for which acknowledgment ofpayment has been received but the “refund window” has not yet expired.In some embodiments, for a period after one of payment and an end of theexpiry period for tendering payment for an online order, a refund may beissued for price changes that occur within the refund window. In someembodiments, the refund window may include the window between a paymentdate and when an item actually ships from a fulfillment enter. In someembodiments, the refund window includes the latest of some or all ofthese events or dates.

Price changes between the purchase price of items as recorded in anorder and the updated prices of the catalog may be identified 2006 andthe purchase price for these items in the pending orders may be updated2008 to reflect the current price. In some embodiments, all changes tothe purchase price for items in an order may be recorded in a pricechange history for the order. This may be used to prevent duplicateprice reductions. Notice of changes in price to pending orders may betransmitted 2010 to the customers associated with these orders.

The method 2000 may additionally include initiating 2012 refunds fororders that were both paid for within the refund window for the orderand for which price changes were identified 2006 following payment. Therefund may be processed according to any of the methods for processingrefunds in response to a refund trigger as described hereinabove.

Upon checkout, a customer may, in accordance with other methodsdescribed herein, provide information identifying the order or thecustomer, which the POS then uses to request order information. Themerchant system receives 2014 the request for order information andtransmits 2016 the current order information, including the currentpurchase price as updated 2008 according to any price changes. The POSthen receives the information and receives tender of payment of thecurrent purchase price. The POS then transmits acknowledgment of paymentto the merchant system 202 a-202 b. The acknowledgment of payment isreceived 2018 and in response, fulfillment of the order is authorized2020 or otherwise initiated.

FIG. 21 illustrates a method 2100 for evaluating the eligibility of anitem for purchase by means of an online ordering with payment at anin-store POS. In some embodiments, in order to prevent abuse or gamingof systems and methods described herein, items may be flagged asineligible for purchase online with payment at an in-store POS. Forexample, someone may maliciously order a large amount of items and thennot pay for them. For example, high demand items at high demand times ofthe year may be flagged as ineligible in order to prevent unavailability(resulting from orders for which payment might not be received) of itemsfor which customers are willing to pay immediately.

Accordingly, the method 2100 may include receiving 2102 a selection ofone or more items from a customer. This may include adding items to anelectronic shopping cart by a customer using a web browser, as known inthe art of ecommerce. The eligibility of the items may be evaluated2104. If one of the items is found 2106 to not be eligible, then atcheckout or at other points in the online transactions, payment methodoptions will be transmitted 2108 for presentation to the customerexcluding an option to pay at a POS. Remaining options may includepayment with a debit or credit card, using store credit, or some othermeans of electronic payment.

If the item is found 2106 to be eligible, the method 2100 may includeevaluating 2110 the quantity of the item. This may include comparing thequantity to a threshold quantity for the item. If the quantity is notfound to be eligible, then payment methods may be presented 2108. Insome embodiments, the quantity used to determine eligibility may includeaggregating quantities for multiple items in the order. For example, aglobal threshold for the amount of items that can be eligible may bedefined for an individual order. In some embodiments, the quantity usedto evaluate eligibility may include evaluating an aggregate quantity forthe items in other pending, i.e., unpaid, orders for the customerassociated with the order. In some embodiments, the quantity may includeaggregating quantities of multiple items for all pending orders for thecustomer.

The method 2100 may include evaluating 2112 the order amount withrespect to a threshold. If the amount exceeds the threshold, thenpayment options are presented 2108. As for the quantity, the orderamount may include aggregating the amount due for all pending, i.e.,unpaid, orders for the customer.

If the item(s), item quantities, and order amount are found to beeligible then payment methods are transmitted 2114 for display to thecustomer, where the payment methods include an option to pay for theorder at a POS.

In some embodiments, more or less of the attributes evaluated in themethod 2100 may be used to evaluate the eligibility of the order. Insome embodiments, if a single item in an order is found to beineligible, an entire order may be deemed ineligible.

FIG. 22 illustrates a method 2200 for specifying the eligibility of anitem for purchase online with payment taking place at an in-store POS.The method 2200 may include defining 2202 a product hierarchy. Itemsoffered for sale may be classified in a hierarchy of categories andsubcategories. The hierarchy may include nodes that are a category or asubcategory of an item. Each node may have as descendants another nodeor a specific item.

To specify eligibility of items, selection of a node may be received2204. An eligibility to be assigned to the node may also be received2206. The eligibility may indicate one or more of whether the node andits descendants is or is not eligible, a quantity threshold, or anamount threshold for the node. The eligibility as defined for the nodemay then be applied 2208 for descendent nodes as well as items of thenode. In some embodiments, application 2208 of eligibility may occur atthe item, where a specific order is analyzed such as discussed belowwith respect to the method of FIG. 23.

The method 2200 may additionally include receiving override selection2210 of a node or item as well as receiving overriding eligibility 2212to be applied to the override selection. The eligibility for theoverride selection may indicate one or more of whether the selected itemis not eligible or selected node and its descendants are not eligible, aquantity threshold, and an amount threshold for the node or item. Theoverride may obviate any eligibility specified for a parent node in thehierarchy. The override eligibility may be applied 2214 to the node oritem and any descendent nodes or items immediately after it is received2212, at the time eligibility of an order is determined (e.g., themethod 2100), or at some other time.

FIG. 23 illustrates a method 2300 for determining the eligibility of anitem for online ordering with payment provided at an in-store POS. Themethod 2300 may include receiving 2302 a selection of one or more itemsfrom a customer. This may include receiving the selection from a webbrowser displayed to the customer on a client device.

An item hierarchy, as discussed above, may be denormalized 2304 orotherwise traversed to determine the eligibility of the item. As notedabove, an eligibility specification applied to a node of the hierarchymay also be applied to descendent nodes. Accordingly, the hierarchy maybe analyzed to determine whether any eligibility restriction has beenapplied to a parent node of any of the selected items. This may includetraversing up the hierarchy until a node with an eligibility restrictionis encountered. In some embodiments, a hierarchy “path” may be stored aspart of an item record indicating the path from an item up through thenodes of the hierarchy to a root node, such that traversal is notnecessary. In such embodiments, the nodes of the path may be analyzedfrom specific to general until an eligibility restriction isencountered. Any other method for traversing a hierarchy may also beused to determine the item eligibility.

The method may further include applying an override 2306. In someembodiments, as noted above, an eligibility specification may be definedspecifically for an item or node that overrides eligibilityspecification for a parent node. Accordingly, the eligibility determined2304 according to the hierarchy may be overridden according toapplication 2306 of the override for an item based on any overridedefinitions. An override specification may impose additionalrestrictions as to one or more of eligibility, quantity eligibility, oramount eligibility. An override specification may also impose fewereligibility restrictions.

In some embodiments, the order of steps 2304 and 2306 may be altered.For example, if an override has been defined, it may be applied 2306 andanalysis of any eligibility defined for the hierarchy, or higher levelsof the hierarchy, may be omitted. If no override is defined, then step2304 may be performed.

One or more payment methods may be selected 2308 according to theeligibility specification determined for the item based on one or bothof steps 2304 and 2306. This may include determining eligibility of theitems of the order or determining the eligibility of the order as awhole, such as according to the method 2100. The selected paymentmethods may then be transmitted 2310 for display to a customer forselection by the customer for payment of the order.

FIG. 24 illustrates a method 2400 for managing inventory in a systemthat permits a customer to make an online order and pay for the order atan in-store POS according to the methods described herein. The method2400 may be executed by a component of the merchant system 202 a-202 b.

The method 2400 may include generating a watermark inventory accordingto an actual inventory. This may include simply making a copy of theactual inventory. The inventory may list items and the quantity of itemsavailable for sale. Portions of the inventory may be associated withindividual fulfillment or storage facilities. As noted above, uponacknowledgment of payment, orders may be assigned to such a facility forfulfillment. The inventory may also include information on expectedinflows of items due to receipt of shipments and expected outflows dueto orders that have been paid for but not shipped.

A customer by means of a browser or other component may request to viewinformation about an item. This request is received 2404. Informationabout the item may be transmitted 2406 to the customer for display. Thetransmitted information may include an item description and/or theavailability of the item according to the watermark inventory. Theavailability information may include an absolute availability per thewatermark inventory, i.e., the item is or is not available, or anavailability date per the watermark inventory, i.e., the item isavailable for purchase now or available as of some future date. Thetransmitted information may also include a purchase price.

As noted above, in some embodiments, eligibility of an item for purchaseby means of online ordering with payment at a POS may be evaluated. Insome embodiments, the quantity of an item that can be eligible forpurchase in this manner may be evaluated based on both availableinventory and a threshold quantity for the item. For example, thethreshold against which a proposed quantity is compared to determineeligibility may be dynamically changed according to available inventory,i.e., reduced as inventory gets low and increased if inventory is high.In some embodiments, the watermark inventory may be used for determininghow to alter the threshold, and in others, the actual inventory may beused.

The method 2400 may further include receiving 2408 an online order forthe item that includes a request to pay for the item at an in-store POS.Upon receiving 2408 such an order, the watermark inventory is updated2410 to indicate that the item is not available for purchase. This mayinclude simply decrementing the number available for purchase. If theorder is found 2412 to be completed, such as after receivingacknowledgment of payment from a POS as described herein, then theactual inventory may be updated 2414 to indicate that the item is nolonger available. This may include decrementing the number of units ofthe item available in the actual inventory.

If the order is found 2416 to have been canceled, then the watermarkinventory may be restored 2418. This may include increasing the numberof units of the item available for sale. Cancellation may be due toexpress cancellation by the customer or cancellation due to failure topay for the order at a POS within the pay period as describedhereinabove.

FIG. 25 illustrates a method 2500 for preventing fraud and abuse ofsystems that allow for online orders to be paid for at an in-store POS.As already noted above, eligibility restrictions for items as well asrestrictions as to the number of items or amount of an order may beimplemented to prevent fraud and abuse and otherwise prevent harm to amerchant due to unpaid orders tying up inventory.

The method 2500 may be used to evaluate customer activity to detectpotentially fraudulent activity. In particular, the method 2500 may beused to prevent usage of the systems and methods described herein totransfer funds from one party to another.

The method 2500 may include receiving 2502 a request for a refund for anorder for which payment was received at a POS. This may includereceiving a refund triggering event as described hereinabove. As notedabove, information such as refund preference and a pick-up person may bespecified by a customer account or input by the customer at the time anorder is made or a refund is requested. The method 2500 may includeevaluating 2504 correspondence between a refund payee and the payer thatpaid at a POS for the order. If the payee and the payer are different,then a flag may be set. In some embodiments, a relationship between thepayer and payee may be evaluated, such as whether they share a last nameor if there is any publicly available indication of a relationshipbetween them. This may include evaluating publicly available social siteinformation or other searchable information on the Internet. The flagmay be cleared if an apparent personal relationship exists between thepayer and payee.

A proximity between a payment store, i.e., the store where payment wastendered, and a refund store may be evaluated 2506. In some embodiments,a customer may be required to specify a choice of refund stores at whicha cash refund is to be received. For example, a list of stores at whicha cash refund may be received may be transmitted for display to thecustomer, and a selection of one or more of the stores may be receivedas the customer's designation of a refund store. If this store is notwithin a distance threshold of the location where payment was tendered,then a flag may be set or the choice of refund stores may be prohibited.In some embodiments, only those stores within a threshold distance fromthe payment store may be transmitted for display and selection. In otherembodiments, a customer selection of a refund store is evaluated and thecustomer is notified that the selection is not appropriate if theselected store is not within the threshold distance from the paymentstore.

Alternatively or additionally, the evaluation of a customer's selectionof a refund store may be performed once an attempt to obtain a refund ismade at a particular store, such as according to the methods describedherein. The proximity of this store to the store where payment was mademay therefore be evaluated 2506 as part of processing the refund. Insuch embodiments, requests for cash refunds originating at a POS that isnot within a proscribed proximity to the store where payment was mademay be denied.

In some embodiments, an aggregation of refunds associated with thecustomer making the request for refund may be evaluated 2508. If thecustomer has a pattern of making orders, paying for them, and thenrequesting refunds, a flag may be set. In some embodiments, the customermay be flagged as ineligible for making online orders having POS paymentas the selected payment method if the aggregate amount exceeds athreshold. In some embodiments, the aggregate amount of refunds foronline orders with POS payment option within a certain time period, suchas a week or month, may be compared to a threshold. If the amount ofrefunds paid out exceeds this threshold, a flag may be set. In someembodiments, the aggregate amount of refunds paid out at an in-store POSmay be compared to a threshold and the customer may be flagged asineligible if this threshold is exceeded.

Accordingly, if a customer is flagged as ineligible, for future ordersthe customer will no longer be presented with the option to pay for anonline order at a POS. In some embodiments, the number of refundrequests may likewise be aggregated and compared to a threshold and usedto flag the order or flag the customer as ineligible in the same manneras for the amount threshold.

The method 2500 may further include taking remedial action according toflags set based on any of the evaluations mentioned herein that mayindicate fraud or abuse of the system. Remedial action may includelimiting the stores at which a cash refund will be paid to those withina threshold distance of the store where payment was received, as notedabove. Remedial action may also include limiting the refund to storecredit. For this option, refund terms indicating this potentiallimitation may be communicated to the customer prior to payment.Remedial action may further include requiring the payee to be anindividual rather than a business or financial institution.

Remedial action may also include requiring that the payee presentidentification upon pick up of a cash refund verifying that the payee isidentical to the individual that provided payment. In such embodiments,the identity of the payee may be verified at the POS and transmitted tothe merchant system 202 a-202 b before or after payment is received.Authorization to provide the refund may be transmitted to the POS onlyafter verification of the payee's identity is received. In otherembodiments, instructions to provide the refund may be transmitted tothe POS only upon verification of the payee's identity as identical tothe payer's identity.

The functionality of the systems and methods described herein may bedivided between different parties. For example, the merchant system 202a-202 b may be owned or controlled by a different entity than the entityowning or controlling the POS or POS host. Likewise, the components ofFIG. 3 may each be owned or controlled by the same or differententities. Accordingly, the methods described herein may additionallyinclude authentication steps whereby the POS authenticates itself to themerchant system 202 a-202 b when transmitting acknowledgment of paymentand where the merchant system 202 a-202 b authenticates itself whencommunicating with the POS.

Likewise, additional steps for transferring funds between entities maybe provided. For example, upon receiving payment at a POS for an order,an entity owning or controlling the POS may electronically transferfunds to an entity corresponding to the order. The transfer may occurfor each order, or a monthly, weekly, or other interval transfer mayoccur for all transactions in a given period. In some embodiments, aclearing house wherein payments received on behalf of an entity areoffset by payments due from the entity in order to reduce the amount ofmoney transferred between entities.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrative,and not restrictive. The scope of the invention is, therefore, indicatedby the appended claims, rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A method for managing online transactionscomprising: receiving, by a server, a request to create an order from acustomer; evaluating, by the server, the order for abusive activity;determining, by the server, that the order does not indicate abusiveactivity; and transmitting, by the server, for display to the customer,payment options including an in-store point of sale (POS) payment optionin response to the determining that the order does not indicate abusiveactivity.
 2. The method of claim 1, further comprising: receiving apayment method selection from among the payment options; determiningthat the payment method selection indicates the in-store POS paymentoption; and in response to the determining that the payment methodselection indicates the in-store POS payment option: receiving a requestfor order information for the order from the POS; transmitting orderinformation to the POS; and receiving acknowledgment of payment for theorder from the POS.
 3. The method of claim 1, wherein evaluating theorder for abusive activity comprises evaluating a quantity of an item inthe order with respect to a threshold, the method further comprising:determining that the quantity of the item is in accordance with thethreshold; and presenting the payment options including an option to payfor the in-store POS payment option in response to the determining thatthe quantity of the item is in accordance with the threshold.
 4. Themethod of claim 3, wherein evaluating the quantity of the item in theorder with respect to a threshold further comprises: aggregating theorder with other orders associated with the same customer; evaluatingthe aggregation of orders with respect to the threshold.
 5. The methodof claim 1, wherein evaluating the order for abusive activity comprisesevaluating an amount due for the order with respect to a threshold, themethod further comprising: determining that the amount due for the orderis in accordance with the threshold; presenting the payment optionsincluding the in-store POS payment option in response to the determiningthat the amount due is in accordance with the threshold.
 6. The methodof claim 5, wherein evaluating the amount due for the order with respectto the threshold further comprises: aggregating the order with otherorders associated with the customer; and evaluating the aggregation oforders with respect to the threshold.
 7. The method of claim 1, whereinevaluating the order for abusive activity comprises evaluatingeligibility an item in the order, the method further comprising:determining that the item is eligible; presenting payment optionsincluding the in-store POS payment option, in response to determiningthat the item is eligible.
 8. The method of claim 1, wherein evaluatingthe order for abusive activity comprises evaluating with respect to athreshold an amount of refunds issued to the customer, the methodfurther comprising: determining that the amount of refunds issued to thecustomer is in accordance with the threshold; presenting the paymentoptions including the in-store POS payment option in response to thedetermining that the amount of refunds is in accordance with thethreshold.
 9. The method of claim 1, wherein evaluating the order forabusive activity comprises evaluating with respect to a threshold anamount of POS-issued refunds for online orders associated with acustomer associated with the order, the method further comprising:determining that the amount of POS-issued refunds issued for onlineorders associated with the customer associated with the order is inaccordance with the threshold; presenting the payment options includingthe in-store POS payment option in response to the determining that theamount of POS-issued refunds issued for online orders associated withthe customer associated with the order is in accordance with thethreshold.
 10. A system for managing online transactions comprising oneor more processors and one or more memory devices operably connected tothe processors, the one or more memory devices storing executable andoperational data effective to cause the one or more processors to:receive a request to create an order from a customer; evaluate the orderfor abusive activity; determining that the order does not indicateabusive activity; and transmit for display to the customer, paymentoptions including the in-store POS payment option in response todetermining that the order does not indicate abusive activity.
 11. Thesystem of claim 10, wherein the executable and operational data arefurther effective to cause the one or more processors to: receive apayment method selection from among the payment options; and determiningthat the payment method selection indicates the in-store POS paymentoption; and in response to determining that the payment method selectionindicates the in-store POS payment option: receive a request for orderinformation for the order from the POS; transmit order information tothe POS; and receive acknowledgment of payment for the order from thePOS.
 12. The system of claim 10, wherein the executable and operationaldata are further effective to cause the one or more processors toevaluate the order for abusive activity by evaluating a quantity of anitem in the order with respect to a threshold, the executable andoperational data further effective to cause the one or more processorsto: determine that the quantity of the item in the order is inaccordance with the threshold; and present the payment options includingthe in-store POS payment option in response to the determining that thequantity of the item is in accordance with the threshold.
 13. The systemof claim 12, wherein the executable and operational data are furthereffective to cause the one or more processors to evaluate the quantityof the item in the order with respect to the threshold by: aggregatingthe order with other orders associated with the same customer; andevaluating the aggregation of orders with respect to the threshold. 14.The system of claim 10, wherein the executable and operational data arefurther effective to cause the one or more processors to evaluate theorder for abusive activity by evaluating an amount due for the orderwith respect to a threshold; and wherein the operational and executabledata being further operable to cause the one or more processors to:determine that the amount due is in accordance with the threshold; andpresent the payment options including the in-store POS payment option inresponse to the determining that the amount due is in accordance withthe threshold.
 15. The system of claim 14, wherein the operational andexecutable data are further effective to cause the one or moreprocessors to evaluate the amount due for the order with respect to thethreshold by: aggregating the order with other orders associated withthe customer; and evaluating the aggregation of orders with respect tothe threshold.
 16. The system of claim 10, wherein the executable andoperational data are further effective to cause the one or moreprocessors to evaluate the order for abusive activity by evaluatingeligibility of an item in the order; and wherein the operational andexecutable data are further effective to cause the one or moreprocessors to: determine that the item is eligible; present the paymentoptions including the in-store POS payment option in response to thedetermining that the item is eligible.
 17. The system of claim 10,wherein the executable and operational data are further effective tocause the one or more processors to evaluate the order for abusiveactivity by evaluating with respect to a threshold an amount of refundsissued to the customer; and wherein the executable and operational dataare further effective to cause the one or more processors to: determinethat the amount of refunds issued to the customer is in accordance withthe threshold; and present the payment options including the in-storePOS payment option in response to the determining that the amount ofrefunds is in accordance with the threshold.
 18. The system of claim 10,wherein the executable and operational data are further effective tocause the one or more processors to evaluate the order for abusiveactivity by evaluating with respect to a threshold an amount of refundsissued at a POS for online orders associated with a customer associatedwith the order; and wherein the executable and operational data arefurther effective to cause the one or more processors to present thepayment options including the in-store POS payment option, only if theamount of refunds is in accordance with the threshold.
 19. A computerprogram product for managing inventory, the computer program productbeing embodied in a computer readable storage medium and comprisingcomputer instructions for: receiving a request to create an order from acustomer; determining that the order indicates abusive activity;transmitting for display to the customer, payment options including anin-store point of sale (POS) payment option in response to thedetermining the order does not indicate abusive activity.
 20. Thecomputer program product of claim 19, further comprising computerinstructions for: receiving a payment method selection from among thepayment options; determining that the payment method selection indicatesthe in-store POS payment option; and in response to the determining thatthe payment method selection indicates the in-store POS payment option:receiving a request for order information for the order from the POS;transmitting order information to the POS; and receiving acknowledgmentof payment for the order from the POS.